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Issue # 1 : 



The Examiner has rejected Claim 57 under 35 U.S.C. 1 12, first and second paragraphs, as failing 
to comply with the enablement requirement and for being indefinite. 

Group #1: Claim 57 

The Examiner has maintained the rejection of Claim 57 under 35 U.S.C. 1 12, first paragraph, by 
simply reiterating that "[i]t is unclear how an Internet connection can be opened if the Internet is 
closed." Appellant again respectfully disagrees with such rejection, since appellant claims that 
"said closure of said Internet permits an Internet connection only to a website specified by said 
Internet-ready device" (emphasis added). It is thus readily apparent that appellant does not claim 
a "complete" closure, but rather a partial one that specifically permits an Internet connection 
only to a website specified by the Internet-ready device. 

In the Examiner's Answer mailed 01/31/2007, the Examiner has argued that "the features upon 
which applicant relies (i.e., partial closure of the Internet) are not recited in the rejected claim(s) 
or disclosed in the specification or the drawings." The Examiner has further argued that "[i]t is 
unclear how an Internet connection can be opened if the Internet is closed" and has suggested 
'that Appellant meant to state "the apparatus wherein said closure of said Internet connection 
permits another Internet connection. . ." or similar language.' 

Appellant respectfully disagrees. First, appellant respectfully points out that page 9, lines 4-10 
of the originally-filed specification, for example, clearly enables appellant's claimed technique 
"wherein said closure of said Internet permits an Internet connection permits an Internet 
connection only to a website specified by said Internet-ready device," as claimed. Of course, the 
above citation is set forth for illustrative purpose only and should not be construed as limiting in 
any manner. 

Second, appellant respectfully asserts that appellant claims that the "Internet is closed in that said 
user never intervenes to provide additional information" (see Claim 12 for context-emphasis 
added) as well as that "said closure of said Internet permits an Internet connection only to a 
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website specified by said Internet-ready device" (see Claim 57-emphasis added), as claimed. 
Thus, it is again emphasized that the Examiner's arguments and interpretation of the claim term 
"closure" improperly implies that such term requires a "complete" closure, which is not the case. 
To the contrary, appellant's claim language itself explicitly requires that "said closure of said 
Internet permits an Internet connection only to a website specified by said Internet-ready 
device," where such emphasized language inherently defines a "partial" closure, not a 
"complete" one. 

Issue # 2 

The Examiner has rejected Claim 57 under 35 U.S.C. 1 12, second paragraph, as being indefinite. 
Group #1: Claim 57 

The Examiner has maintained the rejection of Claim 57 under 35 U.S.C. 1 12, second paragraph, 
by simply reiterating that "[i]t is unclear how an Internet connection can be opened if the Internet 
is closed." Appellant again respectfully disagrees with such rejection, since appellant claims that 
"said closure of said Internet permits an Internet connection only to a website specified by said 
Internet-ready device" (emphasis added). It is thus readily apparent that appellant does not claim 
a "complete" closure, but rather a partial one that specifically permits an Internet connection 
only to a website specified by the Internet-ready device. 

In the Examiner's Answer mailed 01/31/2007, the Examiner has argued that "the features upon 
which applicant relies (i.e., partial closure of the Internet) are not recited in the rejected claim(s) 
or disclosed in the specification or the drawings." The Examiner has further argued that "[i]t is 
unclear how an Internet connection can be opened if the Internet is closed" and has suggested 
'that Appellant meant to state "the apparatus wherein said closure of said Internet connection 
permits another Internet connection. . ." or similar language.' 

Appellant disagrees and respectfully asserts that appellant claims that the "Internet is closed in 
that said user never intervenes to provide additional information" (see Claim 12 for context- 
emphasis added) as well as that "said closure of said Internet permits an Internet connection only 
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to a website specified by said Internet-ready device" (see Claim 57-emphasis added), as claimed 
Thus, it is again emphasized that the Examiner's arguments and interpretation of the claim term 
"closure" improperly implies that such term requires a "complete" closure, which is not the case. 
To the contrary, appellant's claim language itself explicitly requires that "said closure of said 
Internet permits an Internet connection only to a website specified by said Internet-ready 
device," where such emphasized language inherently defines a "partial" closure, not a 
"complete" one. 



Issue # 3: 

The Examiner has rejected Claims 1-12, 18-38, and 44-57 under 35 U.S.C. 102(e) as being 
anticipated by Vaziri (U.S. Patent No. 6,377,570). 

Group #1: Claims 1-10, 12, 18-36, 38, 44-51, and 53-57 



With reference to independent Claims 1 and 27, the Examiner has relied on the following excerpt 
from Vaziri to make a prior art showing of appellant's claimed "protocol handler block for 
receiving and handling messages from said user interface and from said Internet-ready device" 
(see this or similar, but not identical language in each of the foregoing claims). 



"Checking and sending messages will now be explained with reference to 
FIGS. 7D and 7E. To check messages, the user dials #3 to enter message 
checking through the menu. The ISB connects to the ISP and then 
connects through ISP 706 and Internet 712 to POP server 716. Once this 
last connection is achieved, the ISB downloads and plays the first 
message. The user can then dial 1 to repeat, 2 to go to the next 
message or 3 to erase a message, much as he would with an answering 
machine. To send a message, the user dials #4, whereupon the ISB 
connects to the ISP and then connects through ISP 706 and Internet 712 
to SMTP server 718 (the function of the SMTP server having been 
described above) . The user can then record a message and then send it 
via the SMTP server to the recipient's e-mail address. The ISB can be 
configured to impose a time limit on outgoing messages (e.g., 60 
seconds) . The ISB can also be configured to poll the ISP periodically 
(e.g., four times a day or some other interval which is either set in 
the factory or programmed by the user) to check for message and to give 
an indication to the user via an LED or the like when messages are 
waiting . 

The ISB can also be configured to poll the ISP periodically (e.g., four 
times a day or some other interval which is either set in the factory 
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or programmed by the user) , whenever a call is completed over IP, or 
both to check for message and to give an indication to the user via an 
LED or the like when messages are waiting. In one configuration, 
polling takes place only when all three of the following conditions are 
satisfied: (1) the polling period set in the ISB has expired, (2) the 
telephone has not been in use in the last two minutes and (3) no ring 
signal has been received in the last two minutes. Of course, the ISB 
can be equipped with an internal clock, such as those used in 
conventional IBM-compatible PCs, to allow periodic polling. 

Each voice mail message is stored on the recipient's POP server in the 
form of an e-mail message with the sender's e-mail address listed in 
the "From:" field, a standard subject such as "ISB voice mail message" 
and a MIME attachment of the voice mail message in an appropriate sound 
file format. If the recipient checks his e-mail on the POP server with 
a conventional e-mail program such as Eudora, he will see such message 
interspersed among conventional e-mail messages. The ISB can 
distinguish the voice mail messages from the conventional e-mail 
messages by the subject." (Col. 17, line 57 - col. 18, line 33) 



Appellant respectfully asserts that the above excerpt from Vaziri only relates to messages from a 
telephone , not an "Internet-enabled device," as claimed (again, note that the Examiner now relies 
on Vaziri 's help desk computer to meet appellant's claimed "Internet-enabled device"). Further, 
the messages of the above excerpt do not relate to messages from a "user interface" of an 
"apparatus for a user to connect an Internet-ready device to the Internet," as claimed, especially 
since the messages in Vaziri are from a telephone, and not from the help desk computer, as relied 
on by the Examiner. Thus, in no way is there even a suggestion of any sort of " protocol handler 
block for receiving and handling messages from said user interface and from said Internet-ready 
device ." in the manner claimed by appellant (emphasis added). Appellant asserts that such use 
of Vaziri as a dictionary (i.e. by relying on a help desk computer as an Internet-enabled device 
and then relying on the functionality of a telephone) is simply inappropriate, and is further 
evidence that the prior art of record simply does not meet appellant's claims. 



In the Advisory Action mailed 03/30/2006, the Examiner again relied upon Col. 17, line 57 to 
Col. 18, line 33 in Vaziri to make a prior art showing of appellant's claimed technique. Further, 
the Examiner argued that "the messages are converted from phone messages to email messages 
that are capable of being received at the help desk computer." First, appellant respectfully 
disagrees with the Examiner's statement. Appellant respectfully asserts that the excerpt from 
Vaziri merely teaches that a "user can then record a message and then send it via the SMTP 
server to the recipient's e-mail address." Vaziri continues, teaching that "[e]ach voice mail 
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message is stored on the recipient's POP server in the form of an e-mail message." Additionally, 
Vaziri discloses that the " ISB connects to the ISP and then connects through ISP 706 and 
Internet 712 to POP server 716" where "the ISB downloads and plays the first message " 
(emphasis added). 

Clearly, sending a recorded message to an SMTP server, storing the message on the POP server, 
and the ISB downloading and playing the message from the POP server, as in Vaziri, fails to 
support the Examiner's argument that Vaziri teaches "email messages that are capable of being 
received at the help desk computer." More importantly, appellant respectfully asserts that the 
mere disclosure of an ISB that may download and play a message fails to even suggest a 
" protocol handler block for receiving and handling messages from said user interface and from 
said Internet-ready device ," as claimed by appellant (emphasis added). In addition, the 
disclosure of a SMTP server used to send a recorded message and an e-mail program to check 
for e-mail similarly fails to even suggest the same. 

In the Examiner's Answer mailed 01/31/2007, the Examiner has argued that Vaziri teaches "a 
user interface, allowing a user to initiate passing information between the Internet-ready device 
and the Internet (an Internet switch box (ISB) is connected or integrated within the 
telephone... [and] the ISB takes care of all connection procedures necessary to set up and 
maintain the Internet telephone call...)... [and] a protocol handler block for receiving and 
handling messages from the user interface and from the Internet-ready device (the ISB includes 
PC-compatible microprocessor 201... microprocessor 201 executes software 
architecture... [including] TCP/UDP driver 2A13, IP driver 2A15 and PP driver 2A17 [which] 
serve as. . .embedded networking software for packetizing data and allowing communication with 
the Internet - see Vaziri, Fig. 2 and 2A, col. 9, line 13 - col. 10, line 13)." Further, the Examiner 
has argued that "[t]he Vaziri reference teaches the ISB capable of using the TCP/IP protocol 
suite, as detailed above." 

The Examiner has additionally argued that 'Stevens discusses that the TCP/IP protocol suite 
contains four layers, one of which is the transport layer, which "provides a flow of data between 
two hosts," one of the transport layer protocols being TCP" and that "[t]hese two hosts are 
equivalent to appellant's user interface and the Internet, and as communication is passed between 
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the user interface as the Internet-ready device, the two hosts can also be equivalent to the 
appellant's apparatus and the Internet-ready device. The Examiner has concluded that Vaziri 
"teaches a protocol handler block (transport layer) for receiving (acknowledging received 
packets) and handling messages from the user interface (make certain the other end [the Internet] 
acknowledges packets that are sent - see Stevens, page 2, "the transport layer," reference 
attached in the Appendix) and from the Internet-ready device (Vaziri, Fig. 12, element 908; a 
computer or data terminal 908 and a specially equipped ISB 100HD connected to computer or 
data terminal via a serial port or other connection. . ." 

Appellant notes the Examiner has relied on the Stevens reference, which constitutes a reference 
separate from that in the relevant rejection under 35 U.S.C. 102(e), and is thus improper. 
Further, it is noted that the Examiner fails to cite specific motivation in the relevant reference to 
support the case for combining the Stevens reference. The Examiner is reminded that the 
Federal Circuit requires that there must be some logical reason apparent from the evidence of 
record that would justify the combination or modification of references. In re Regel, 188 USPQ 
132 (CCPA 1975). Thus, the reliance on the Stevens reference, on its face, is clearly improper. 

In addition, appellant respectfully disagrees with the Examiner's arguments and asserts that 
Vaziri merely discloses that "FIG. 4 shows the back or bottom view of an ISB" where the 
"[b]ack or bottom panel 402 can include telephone jack 404 for connection to telephone 211, 
telephone jack 406 for connection to telephone line 212, optional port (serial, parallel, universal 
serial bus (USB), etc.) 408 for connection to another device such as a PC, and power jack 410" 
(Col 12, lines 1-6 - emphasis added). Further, Vaziri discloses that "[i]f the ISB is intended for 
use with a connection other than to the analog PSTN, such as a connection to an ISDN line or to 
a cable modem , jack 406 can be modified accordingly" (Col. 12, lines 13-16 - emphasis added). 
In addition, Vaziri discloses that "[t]he user simply plugs telephone 211 into jack 404 , a cord 
from telephone line 211 into jack 406 and a power adapter into power jack 410 to supply power 
from a wall outlet" (Col. 12, lines 24-26 - emphasis added). 

However, the mere disclosure of an ISB with three ports, one for the telephone line, ISDN line, 
or cable modem, one for connecting a telephone , and another for connecting to another device 
such as a PC, as in Vaziri, fail to suggest a " protocol handler block for receiving and handling 
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messages from said user interface and from said Internet-ready device " where "the second port 
connects to said Internet-ready device capable of communicating utilizing Internet-related 
protocols ," in the context as claimed by appellant (emphasis added). Clearly, the telephone as 
connected to port 404, as in Vaziri, fails to meet an " Internet-ready device capable of 
communicating utilizing Internet-related protocols ," in the manner as claimed by appellant 
(emphasis added). 

Further, the Examiner has argued that Vaziri "teaches a protocol handler block (transport layer) 
for receiving (acknowledging received packets) and handling messages from... the Internet-ready 
device (Vaziri, Fig. 12, element 908; a computer or data terminal 908 and a specially equipped 
ISB 100HD connected to computer or data terminal via a serial port or other 
connection. .. [where] [p]ersonal computers that are multimedia capable in terms of 
possessing... an adequate modem... as well as an account with an online service provider (ISP) 
for connection to the Internet - see Vaziri, col. 22, lines 27-33 and col. 1, lines 31-41)." In 
addition, the Examiner has argued that "[t]he computer could be connected to the ISB via a 
connection such as a telephone line that would enable use of the modem, which has TCP/IP 
capabilities" and "[t]hus both the ISB and the personal computer are capable of utilizing a 
protocol handler block." 

Appellant respectfully disagrees with the Examiner's arguments and asserts that Vaziri merely 
discloses that "FIG. 9 shows a connection between a customer's location 900C and an agent's 
position 900HD at the help desk" where "[t]he help desk has one or more call center positions 
900HD, each equipped with a standard telephone 21 1HD , a computer or data terminal 908 and a 
specially equipped ISB 100HD connected to computer or data terminal 908 via a serial port or 
other connection such as serial port 408 of FIG. 4" (Col. 22, lines 27-33 - emphasis added). 
Further, Vaziri discloses that "[t]he ISBs 100C and 100HD perform a modem handshaking and 
then start a PPP link between them " (Col. 22, lines 55-57 - emphasis added) so that the "[t]he 
agent can use ISB 100HD to access, program, upgrade and test customer's ISB 100C" (Col. 22, 
lines 35-37 - emphasis added). 

In addition, Vaziri discloses that "Microprocessor 201 executes the software architecture shown 
in FIG. 2A" where the "[s]oftware architecture 2A01 is based on a space-efficient embedded 
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operating system such as ROM DOS 2A03, which includes application component 2A05 and 
maintenance component 2A07... [which] interacts with the following drivers" (Col. 10, lines 1- 
6). Still yet, Vaziri discloses that the ' Ttlelephone interface driver 2A09 allows the software to 
interact with telephone set 211 " and "TCP/UDP driver 2A13, IP driver 2A15 and PPP driver 
2A17 serve as modifiable, embedded networking software for packetizing data and allowing 
communication with the Internet " (Col. 10, lines 6-14 - emphasis added). 

However, the mere disclosure that the helpdesk ISB has a computer or data terminal connected 
via the serial port for accessing, programming, upgrading, and testing the customer's ISB via a 
PPP link established between the help desk ISB and the customer ISB by the PPP driver of 
Microprocessor 201 that allows for communication over the Internet, as in Vaziri, simply fails to 
meet a " protocol handler block for receiving and handling messages from said user interface and 
from said Internet-ready device ," in the manner as claimed (emphasis added). Clearly, the 
microprocessor packetizing data and allowing communication with the Internet between the help 
desk ISB and the customer ISB, as in Vaziri, fail to meet " protocol handler block for receiving 
and handling messages... from said Internet-ready device ." in the manner as claimed (emphasis 
added). 

Appellant again emphasizes that Vaziri only teaches that "the ISB connects to the ISP and then 
connects through ISP 706 and Internet 712 to POP server 716" to download and play the first 
message and that "the ISB connects to the ISP and then connects through ISP 706 and Internet 
712 to SMTP server 718" to send a message (see Col. 17, line 57-Col. 18, line 1). Thus, the ISB 
only directly receives messages from an ISP and from a telephone connected to the ISB and 
utilized by the user. Clearly, the ISB in Vaziri is not disclosed to specifically include "a protocol 
handler block for receiving and handling messages from said user interface and from said 
Internet-ready device , and for sending on said handled messages to a network stack block," let 
alone where the "user interface... [allows] a user to initiate passing information between said 
Internet-ready device and said Internet, and [that has] associated indicators to indicate to said 
user that said passing of information that was initiated by said user in complete," in the context 
claimed by appellant. 
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With additional reference to independent Claims 1 and 27, the Examiner has relied on the 
following excerpt from Vaziri to make a prior art showing of appellant's claimed protocol 
handler block for receiving and handling messages from said user interface and from said 
Internet-ready device, and for "sending on said handled messages to a network stack block" (see 
this or similar, but not identical language in each of the foregoing claims). 

"More specifically, the ISB stores device, server, billing, and owner 
information and a friends directory. The device information is 
typically programmed into the ISB at the factory and includes the 
serial number, the manufacturing date, the hardware version, the 
software version, and the feature key, which identifies those features 
which the ISB implements. The server information includes the IP 
addresses for the various servers which the ISB needs to access, such 
as the primary and backup ISBSSs. The owner information includes the 
telephone number, the ISP access telephone number, any scripting 
required to log onto the ISP, logon name and password, the domain names 
or IP addresses for the SMTP and POP servers for e-mail, the e-mail 
address, and the e-mail password. The SMTP server implements the simple 
mail transfer protocol (SMTP) for sending e-mail, while the POP server 
implements the post office protocol (POP) for receiving e-mail. Many 
ISPs use the same server for both protocols. Other mail protocols exist 
and can be used instead." (Col. 13, lines 13-31) 

Appellant respectfully asserts that the above excerpt from Vaziri only relates to information with 
respect to the device, server, billing, owner information and friends directory that the Internet 
switch box (ISB) stores. Further, by virtue of the above arguments, there is not even a 
suggestion of any sort of messages , let alone sending handled messages from said user interface 
and from said Internet-ready device to a network stack block , in the manner claimed by 
appellant. 

In the Office Action dated 01/27/2006, the Examiner has argued that such excerpt in Vaziri 
teaches that "the ISB stores server information. . .the server information includes the IP address 
for various servers which the ISB needs to access... the domain names or IP addresses for the 
SMTP and POP servers for e-mail... the SMTP server implements the simple mail transfer 
protocol (SMTP) for sending e-mail, which the POP server implements the post office protocol 
(POP) for receiving e-mail." Appellant again respectfully disagrees and asserts that the ISB only 
stores "device, server, billing, and owner information and a friends directory," none of which 
meet any sort of "sending on said handled messages ," as appellant specifically claims (emphasis 
added). 
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In the Advisory Action mailed 03/30/2006, the Examiner has again relied upon Col. 13, lines 13- 
31 to make a prior art showing of appellant's claimed technique. However, Vaziri's disclosure 
of using SMTP "for sending e-mail" and POP "for receiving e-mail" fails to meet "sending on 
said handled messages [from said user interface and from said Internet-ready device] to a 
network stack block ," as claimed by appellant (emphasis added). In addition, the Examiner 
relied upon Col. 2, line 8 and the mere disclosure of packets being sent over the Internet using 
TCP/IP. Appellant asserts that the Examiner's argument that "[a] network stack block is 
inherent in the TCP/IP protocol" still fails to take into consideration the full weight of appellant's 
claim language, namely "sending on said handled messages ," in the context claimed (emphasis 
added). 

In the Examiner's Answer mailed 01/3 1/2007, the Examiner has argued that "the Vaziri 
reference teaches the ISB capable of using the TCP/IP protocol suite" and that 'Stevens discusses 
that the TCP/IP protocol suite contains four layers, one of which is the network layer, which 
"handles the movement of packets around the network," one of the network layer protocols being 
IP. ' The Examiner has further argued that 'Stevens teaches "every piece of TCP . . . data that gets 
transferred around the internet goes through the IP layer.'" 

Appellant respectfully disagrees. Specifically, appellant again respectfully notes the Examiner 
has relied on the Stevens reference, which constitutes a reference separate from those in the 
relevant rejection under 35 U.S.C. 102(e), and that the Examiner fails to cite specific motivation 
in the relevant reference to support the case for combining the Stevens reference. Thus, the 
reliance on the Stevens reference, on its face, is clearly improper. Additionally, appellant 
respectfully points out that teaching that an ISB includes a microcontroller that executes a 
TCP/UDP driver, as in Vaziri, fails to meet "sending on said handled messages [from said user 
interface and from said Internet-ready device] to a network stack block ," as claimed by appellant 
(emphasis added). 

Still with respect to independent Claims 1 and 27, the Examiner has relied on Figure 3 elements 
304, 306, 307, and 3 1 1 along with Col. 1 1 , lines 1 1-22 in Vaziri to make a prior art showing of 
appellant's claimed "indicators to indicate to said user that said passing of information that was 
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initiated by said user is complete." Appellant emphasizes, however, that in the Office Action 
dated 1 1/03/05, the Examiner admitted that Vaziri did not teach such claim language (see page 5 
of the foregoing Office Action). 



Nevertheless, appellant respectfully asserts that Vaziri expressly discloses that elements 304, 
306, 307 and 311 are LEDs located on the ISB, and that such "LEDs may be used to indicate 
whether the power is on or off, the status of an Internet call attempt and whether any messages 
are waiting" along with "whether the menu feature is in use or whether an upgrade to the ISB 
software is available." Clearly, none of the functions taught by Vaziri meet appellant's claimed 
"indicators to indicate to said user that said passing of information that was initiated by said user 
is complete ," as claimed (emphasis added). 

In the Advisory Action mailed 03/30/2006, the Examiner argued that items 304, 306, 307, and 
311 of Figure 3 and Col. 11, lines 11-22 disclose "status indicator LEDs... [which] may be used 
to indicate the status of an Internet call attempt." See below: 



"FIG. 3 shows a front or top view of an ISB. Front or top panel 302 may 
include a logo 305. Status indicator LEDs 304, 306, 307 and 311 may be 
provided. Three of these LEDs may be used to indicate whether the power 
is on or off, the status of an Internet call attempt and whether any 
messages are waiting. The fourth can be used in various ways, such as 
to indicate whether the menu feature is in use or whether an upgrade to 
the ISB software is available (in which case the software can be 
upgraded in a manner to be described below) . Of course, other 
configurations of LEDs can be used, as can other interfaces such as an 
alphanumeric LCD display." (Col. 11, lines 11-22 - emphasis added) 



However, the mere disclosure of status indicator LEDs of which one may be used to indicate 
"the status of an Internet call attempt" fails to even suggest "indicators to indicate to said user 
that said passing of information that was initiated by said user is complete ," as claimed by 
appellant (emphasis added). 




FIG. 3 
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In the Examiner's Answer mailed 01/31/2007, the Examiner has again argued that Col. 11, lines 
11-22 and Fig. 3, elements 304, 306, 307, and 311 teach that "[s]tatus indicator LEDs may be 
provided" and that "[t]hree of these LEDs may be used to indicate... whether any messages are 
waiting. . . to indicate to said user that said passing of information that was initiated by the user is 
complete." The Examiner has also argued that Col. 18, lines 5-10 teaches that "the ISB can be 
configured to poll the ISP periodically (programmed by the user) to check for message [sic] and 
to give an indication to the user via an LED or the like when messages are waiting." 

Appellant disagrees and respectfully points out that the excerpts from Vaziri relied upon by the 
Examiner simply teach that "[fjhree of these LEDs may be used to indicate... the status of an 
Internet call attempt and whether any messages are waiting " (col. 11, lines 13-16 - emphasis 
added). Additionally, the excerpts teach that "[t]he ISB can also be configured to poll the ISP 
periodically... to check for message and to give an indication to the user via an LED or the like 
when messages are waiting" (Col. 18, lines 5-10). However, the mere disclosure of status 
indicator LEDs which may be used to indicate "the status of an Internet call attempt" and 
"whether any messages are waiting," as in Vaziri, fail to even suggest "indicators to indicate to 
said user that said passing of information that was initiated by said user is complete ." as 
claimed by appellant (emphasis added). Clearly, an LED indicating that messages for the user 
are waiting, as in Vaziri, fails to suggest that "said passing of information that was initiated by 
said user is complete," in the manner as claimed by appellant (emphasis added). 

The Examiner is reminded that a claim is anticipated only if each and every element as set forth 
in the claim is found, either expressly or inherently described in a single prior art reference. 
Verdegaal Bros. v. Union Oil Co. Of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. 
Cir. 1987). Moreover, the identical invention must be shown in as complete detail as contained 
in the claim. Richardson v. Suzuki Motor Co.868 F.2d 1226, 1236, 9USPQ2d 1913, 1920 (Fed. 
Cir. 1989). The elements must be arranged as required by the claim . 

This criterion has simply not been met by the Vaziri reference, as noted above. 



Group #2: Claim 52 
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With respect to independent Claim 52, the Examiner has relied on the following excerpts from 
Vaziri to make a prior art showing of appellant's claimed "user interface block [used] to connect 
to said Internet-ready device" (see Claim 52). 



"A relatively inexpensive interface device, referred to as an Internet 
switch box (ISB) , is connected to or integrated within the telephone. 
While the user must possess access to the Internet either directly or 
via an Internet Service Provider (ISP) in order to use the ISB, the 
user will not be subject to toll charges other than those incurred 
using the PSTN to establish the Internet telephone call. The user does 
not need to understand how a computer works or how to use any PCIT 
software, since the ISB can be preprogrammed to dial an ISP and to 
connect via SLIP or PPP. The user need only know how to dial the call 
using normal PSTN dialing procedures and then simply switch the call to 
an Internet connection, if available and desirable. Other than the user 
pressing a button (either on the ISB or telephone keypad) to initiate 
the Internet telephone call, the ISB takes care of all connection 
procedures (i.e., handshaking) necessary to set up and maintain the 
Internet telephone call. While both..." (Col. 3, lines 21-37) 

"As indicated, an ISB may be incorporated into a telephone or be a 
standalone adjunct device connected between the telephone and the 
telephone line. Additionally, ISB's may be..." (Col. 3, lines 64-66) 

"FIG. 4 shows the back or bottom view of an ISB. Back or bottom panel 
402 can include telephone jack 404 for connection to telephone 211, 
telephone jack 406 for connection to telephone line 212, optional port 
(serial, parallel, universal serial bus (USB), etc.) 408 for connection 
to another device such as a PC, and power jack 410." (Col. 12, lines 1- 
6; see also Figure 4) 



In the Office Action dated 01/27/2006, the Examiner has responded to appellant's arguments by 
relying on Vaziri's disclosure of a help desk computer or data terminal (item 908 of Figure 9) to 
meet appellant's claimed "Internet-ready device." Appellant respectfully asserts that, if the 
Examiner now relies on the help desk computer of Vaziri to meet appellant's claimed "Internet- 
ready device," the remaining claim elements are simply not met. 



Specifically, the help desk computer in Vaziri uses an Internet switch box (ISB) to connect to the 
Internet. As shown in Figure 9, the ISB 100HD is separate from the help desk computer 908. 
Furthermore, Vaziri even discloses that the "specially equipped ISB 100HD [is] connected to 
[the] computer or data terminal 908 via a serial port or other connection such as serial port 408 of 
Figure 4" (see Col. 22, lines 27-33). Appellant notes that Vaziri only teaches that the ISB may 
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be "incorporated into a telephone," but not within the help desk computer (see Col. 3, lines 21-23 
and 64-66). Thus, Vaziri does not teach an "apparatus for a user to connect to an Internet-ready 
device to the Internet, where said apparatus is embedded into said Internet-ready device " and 
where the apparatus comprises "a user interface block to connect to said Internet-ready device," 
as claimed by appellant (emphasis added). 



In the Advisory Action mailed 03/30/2006, regarding appellant's claimed "apparatus for a user to 
connect to an Internet-ready device to the Internet, where said apparatus is embedded into said 
Internet-ready device " (emphasis added), the Examiner cites Larson below from the MPEP. 



In re Larson, 340 F.2d 965, 968, 144 USPQ 347, 349 (CCPA 1965) (A claim 
to a fluid transporting vehicle was rejected as obvious over a prior 
art reference which differed from the prior art in claiming a brake 
drum integral with a clamping means, whereas the brake disc and clamp 
of the prior art comprise several parts rigidly secured together as a 
single unit. The court affirmed the rejection holding, among other 
reasons, "that the use of a one piece construction instead of the 
structure disclosed in [the prior art] would be merely a matter of 
obvious engineering choice."). 

The Examiner goes on to argue that "[b]ecause the Internet-ready device and the apparatus have 
the same functionality whether the apparatus is embedded in the Internet-ready device or not, the 
rejection stands." 



Appellant respectfully disagrees with such assertion. First, attention is directed to Schenck 
below. 



Schenck v. Nortron Corp., 713 F.2d 782, 218 USPQ 698 (Fed. Cir. 1983) 
(Claims were directed to a vibratory testing machine (a hard-bearing 
wheel balancer) comprising a holding structure, a base structure, and a 
supporting means which form "a single integral and gaplessly continuous 
piece." Nortron argued that the invention is just making integral what 
had been made in four bolted pieces. The court found this argument 
unpersuasive and held that the claims were patentable because the prior 
art perceived a need for mechanisms to dampen resonance, whereas the 
inventor eliminated the need for dampening via the one-piece gapless 
support structure, showing insight that was contrary to the 
understandings and expectations of the art.)." 

Appellant notes that the claimed apparatus does not have the same functionality whether the 
apparatus is embedded in the Internet-ready device or not, as purported by the Examiner. As 
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indicated in the Background of the originally filed specification, many problems exist when 
using an apparatus in conjunction with a separate Internet-ready device. As further set forth in 
the originally filed specification, the claimed invention is thus cost affordable to embed into 
other devices, etc. Thus, like Schenck, appellant's novel integrated feature shows insight that 
was contrary to the understandings and expectations of the prior art, for the reasons noted above. 

In the Examiner's Answer mailed 01/31/2007, the Examiner cites in re Hirao below and asserts 
that 'the recitation "an apparatus for a user to connect to an Internet-ready device to the Internet, 
wherein said apparatus is embedded into said Internet-ready device" has not been given 
patentable weight because the recitation occurs in the preamble.' 

In re Hirao, 535 F. 2d 67, 190 USPQ 15 (CCPA 1976) "[a] preamble is 
generally not accorded any patentable weight where it merely recites 
the purpose of a process or the intended use of a structure , and where 
the body of the claim does not depend on the preamble for completeness 
but, instead, the process steps or structural limitations are able to 
stand alone" (emphasis added) . 

Appellant disagrees and respectfully points out that the preamble in Claim 52 does more than 
merely recite the purpose or intended use of the claimed apparatus by requiring such apparatus to 
be "embedded into said Internet-ready device," as claimed by appellant. Additionally, appellant 
notes that the body of the claim does in fact depend on the preamble for completeness, as the 
phrase "wherein said apparatus is embedded into said Internet-ready device," as claimed by 
appellant, unquestionably modifies appellant's claimed "apparatus for a user to connect an 
Internet-ready device to the Internet." As a result, In re Hirao does not apply, and the preamble 
should be given patentable weight. 

Also, attention is drawn to In re Stencel, 828 F.2d 751, 4 USPQ2d 1071 (Fed. Cir. 1987), which 
states that, [i]n claims directed to articles and apparatus, any phraseology in the preamble that 
limits the structure of that article or apparatus must be given weight." As noted above, 
appellant's claimed embedded into said Internet-ready device (in the preamble) clearly limits the 
structure of the claimed apparatus in a way that is novel over the prior and which addresses the 
previously discussed problems with the prior art. Again, the preamble should be given 
patentable weight. It is also noted that the emphasized limitations set forth above have yet to be 
adequately addressed by the Examiner, per the arguments set forth hereinabove. 
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Also in the Examiner's Answer mailed 01/31/2007, the Examiner has argued that "Vaziri teaches 
an apparatus for a user to connect to an Internet-ready device (Fig. 4 shows the back or bottom 
view of an ISB [...where the] [b]ack or bottom panel can include... telephone jack 406 for 
connection to telephone line... 408 for connection to another device such as a PC - see Vaziri, 
Fig. 4, elements 406 and 408; col. 12, lines 1-6) to the Internet (an Internet switch box (ISB) is 
connected to or integrated within the telephone... other than the user pressing a button (either on 
the ISB or telephone keypad) to initiate the Internet telephone call, the ISB takes care of all 
connection procedures necessary to set up and maintain the Internet telephone call - see Vaziri, 
col. 3, lines 21-37)." 

Appellant respectfully disagrees and asserts that Vaziri merely discloses that "[o]ther than the 
user pressing a button (either on the ISB or telephone keypad) to initiate the Internet telephone 
cal l, the ISB takes care of all connection procedures (i.e., handshaking) necessary to set up and 
maintain the Internet telephone call" (Col. 3, lines 33-35 - emphasis added). However, the mere 
disclosure that the user presses a button on the ISB or the telephone keypad to initiate the 
Internet telephone call , as in Vaziri, simply fails to even suggest "a user interface block [used] to 
connect to said Internet-ready device " (emphasis added), as claimed by appellant. Clearly, the 
user pressing a button to initiate the Internet telephone call , as in Vaziri, fails to suggest 
"connecting] to said Internet-ready device ," in the manner as claimed by appellant (emphasis 
added). 

Again, the foregoing anticipation criterion has simply not been met by the above reference, as 
noted above. 

Group #3: Claims 11 and 37 

With respect to Claim 1 1 et al, the Examiner has relied on Col. 3, lines 64-66 in Vaziri to make 
a prior art showing of appellant's claimed apparatus "added easily to any of, but not limited to: 
set-top-boxes; Ethernet hubs; and hubs that are attached to new home networking standards." 
Appellant respectfully asserts that such excerpt only teaches that the "ISB may be incorporated 
into a telephone." Clearly, a telephone , as solely disclosed in Vaziri, does not meet appellant's 
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claimed "set-top-boxes; Ethernet hubs; and hubs that are attached to new home networking 
standards." 

In the Advisory Action mailed 03/30/2006, the Examiner argued that Col. 3, lines 64-66 in 
Vaziri teaches a "standalone adjunct device." However, appellant respectfully disagrees and 
asserts that Vaziri discloses "an ISB [which] may be incorporated into a telephone or be a 
standalone adjunct device connected between the telephone and the telephone line " (emphasis 
added). Clearly, a standalone device connected between a telephone and telephone line fails to 
even suggest "set-top-boxes; Ethernet hubs; and hubs that are attached to new home networking 
standards," as claimed by appellant. 

In the Examiner's Answer mailed 01/31/2007, the Examiner has argued "that Vaziri teaches the 
use of an ISBSS which is a server that prov ides connection information for ISBs" and states that 
'the IEEE Authoritative Dictionary of IEEE Standards Terms defines a "hub" as "a device to 
provide connectivity between data terminal equipments'" and that "in the broadest reasonable 
interpretation in light of the supporting disclosure, Vaziri teaches the apparatus (an ISB) added 
(connected) to an Ethernet hub." The Examiner has further relied on the following excerpt from 
Vaziri to make a prior art showing of appellant's claim language. 

"...language. The primary purpose of the ISBSS, but not the exclusive 
function, is to provide connection information for two ISBs to engage 
in an IT call, since it is contemplated that the ISBs will not exchange 
information during the PSTN portion of the call. In addition, the ISBSS 
documents each completed call and each request for any other service, 
such as voice messaging and software upgrade requests, requested from 
ISBs and supported by the vendor of the ISBs. 

The ISBSS is an iterative server. The server functions can..." (Col. 
18, lines 40-49) 

Appellant disagrees with the Examiner's arguments and respectfully asserts that the excerpt 
relied on by the Examiner merely teaches that an ISBSS " provide|"s] connection information for 
two ISBs to engage in an IT call" (emphasis added). Additionally, Vaziri discloses that "[t]he 
ISBSS is an iterative server " (Col. 18, line 49 - emphasis added). Simply disclosing that a server 
provides connection information for two ISBs, as in Vaziri, fails to teach an apparatus "added 
easily to any of, but not limited to: set-top-boxes; Ethernet hubs; and hubs that are attached to 
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new home networking standards," as claimed by appellant (emphasis added). For example, an 
iterative service that provides connection information, as in Vaziri, simply fails to meet an 
"Ethernet hub," in the manner as claimed by appellant. 

Again, the foregoing anticipation criterion has simply not been met by the above reference, as 
noted above. 

Issue # 4: 

The Examiner has rejected Claims 13-16, and 39-42 under 35 U.S.C. 103(a) as being 
unpatentable over Vaziri in view of Himmel et al. (U.S. Patent No. 6,480,852). 

Group #1: Claims 13-14 and 39-40 

Appellant respectfully asserts that the subject matter of such claims is deemed allowable in view 
of the arguments made hereinabove with respect to the Issue #3, Group #1 . 

Group #2: Claims 15 and 41 

With respect to Claim 15 et al, the Examiner has relied on Col. 14, line 55-Col. 15, line 2 in 
Vaziri to make a prior art showing of appellant's claimed "key code for passing from said 
Internet-ready device to said Internet, whereupon a pre-agreed upon algorithm is used to generate 
a response, whereupon said response is sent back to said Internet-ready device, thereby 
authenticating said Internet connection to said Internet-ready device." 

Appellant respectfully asserts that such excerpt only generally teaches that the "ISB and the ISP 
perform any authentication procedure required" and that "the ISB and the ISP then start 
communication by PPP, and PAP (the password authentication protocol) is carried out if no 
authentication has been performed before." Clearly, only generally mentioning an authentication 
procedure and a default password authentication protocol, as in Vaziri, does not meet appellant's 
specific claim language, namely that "a pre-agreed upon algorithm is used to generate a 
response , whereupon said response is sent back to said Internet-ready device, thereby 
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authenticating said Internet connection to said Internet-ready device," as claimed by appellant 
(emphasis added). 



In the Advisory Action mailed 03/30/2006, the Examiner again argued that Col. 14, lines 55-66 
in Vaziri discloses appellant's claimed technique of "a pre-agreed upon algorithm [that] is used 
to generate a response." 



"Connection to the ISP will now be explained with reference to FIG. 7B. 
The modem is initialized, and telephone line 212 is monitored for a 
dial tone. ISB 100 dials the ISP access number to connect via PSTN 702 
to modem rack 704 of the ISP. The modem of the ISB and a modem reached 
in modem rack 704 negotiate the baud rate and the protocol, whereupon 
ISB 100 is connected to the facilities of ISP 706. The ISB and the ISP 
perform any authentication procedure required, and the ISB selects 
"PPP" from the ISP's logon menu, if any. The ISB and the ISP then start 
communication by PPP, and PAP (the password authentication protocol) is 
carried out if no authentication has been performed before. The ISB is 
then connected by TCP to the ISP and thus via line 708, such as a Tl or 
T3 line or the like, to Internet backbone 710. If the call to the ISP 
results in a busy signal, the user can simply wait and call again. 
Alternatively, the ISB can be configured to store and dial multiple 
access numbers for one or more ISPs.' (Col. 14, lines 55-66 - emphasis 
added) 



Appellant respectfully asserts that the excerpt from Vaziri relied upon by the Examiner merely 
discloses that "[t]he ISB and the ISP perform any authentication procedure required " (emphasis 
added). Further, Vaziri discloses that "[fjhe ISB and the ISP then start communication by PPP, 
and PAP (the password authentication protocol) is carried out if no authentication has been 
performed before " (emphasis added). However, the mere disclosure that the ISB and the ISP 
perform authentication and PAP if no authentication has been performed before fails to even 
suggest a "key code for passing from said Internet-ready device to said Internet, whereupon a 
pre-agreed upon algorithm is used to generate a response , whereupon said response is sent back 
to said Internet-ready device, thereby authenticating said Internet connection to said Internet- 
ready device," as claimed by appellant (emphasis added). Clearly, Vaziri' s disclosure of using 
PAP fails to even suggest a technique "whereupon a pre-agreed upon algorithm is used to 
generate a response," as claimed by appellant. 



In the Examiner's Answer mailed 01/31/2007, the Examiner has simply repeated the previous 
grounds of rejection. Appellant respectfully disagrees and again asserts that the excerpt in Vaziri 
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relied on by the Examiner only generally teaches that the "ISB and the ISP perform any 
authentication procedure required" and that "the ISB and the ISP then start communication by 
PPP, and PAP (the password authentication protocol) is carried out if no authentication has been 
performed before." However, generally mentioning an authentication procedure and a default 
password authentication protocol, as in Vaziri, does not meet appellant's specific claim 
language, namely that "a pre-agreed upon algorithm is used to generate a response , whereupon 
said response is sent back to said Internet-ready device, thereby authenticating said Internet 
connection to said Internet-ready device," as claimed by appellant (emphasis added). Clearly, 
the disclosure of using PAP if no prior authentication has been performed, as in Vaziri, fails to 
suggest "a pre-agreed upon algorithm is used to generate a response," in the manner as claimed 
by appellant (emphasis added). 

To establish a prima facie case of obviousness, three basic criteria must be met. First, there must 
be some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to combine 
reference teachings. Second, there must be a reasonable expectation of success. Finally, the prior 
art reference (or references when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the reasonable expectation of 
success must both be found in the prior art and not based on applicant's disclosure. In re 
Vaeck,9Al F.2d488, 20 USPQ2d 1438 (Fed.Cir.1991). 

Appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, fail to teach or 
suggest all of the claim limitations, as noted above. 

Group #3: Claims 16 and 42 

With respect to Claim 16 et al, the Examiner has again relied on Col. 14, line 55-Col. 15, line 2 
in Vaziri to make a prior art showing of appellant's claimed "used in reverse to prevent 
unauthorized Internet-ready devices from accessing a particular site." Appellant respectfully 
asserts that such excerpt from Vaziri only relates to authenticating an ISB with an ISP, and not 
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"to prevent unauthorized Internet-ready devices from accessing a particular site," as appellant 
claims (emphasis added). 

In the Advisory Action mailed 03/30/2006, the Examiner argued that "[i]t is inherent that if a 
user cannot be authenticated, then he or she is not authorized to access any site." Appellant 
respectfully asserts that the Examiner's inherency argument for authentication fails to even 
address the full weight of appellant's claimed technique "used in reverse to prevent unauthorized 
Internet-ready devices from accessing a particular site." Clearly, the mere disclosure of PAP 
during authentication, fails to even suggest "preventing] unauthorized Internet-ready devices 
from accessing a particular site ." as claimed by appellant (emphasis added). 

In the Examiner's Answer mailed 01/31/2007, it appears as though the Examiner is simply 
relying on an inherency argument by stating that "[ljogging on to an ISP usually results in the 
user being presented with a homepage" and "[i]f during the authentication procedure between the 
ISB and the ISP, the ISB is not granted access to the ISP... the ISB is not permitted to logon to 
the ISP, and thus the ISB will not be presented with the ISP homepage (a particular site)." 

Appellant respectfully disagrees. In particular, appellant respectfully asserts that the excerpt 
from Vaziri relied on by the Examiner teaches that "[t]he ISB and the ISP perform any 
authentication procedure required, and... [t]he ISB and the ISP then start communication by 
PPP, and PAP (the password authentication protocol) is carried out if no authentication has been 
performed before" where "[t]he ISB is then connected by TCP to the ISP." Nowhere in the cited 
excerpt does Vaziri mention the user being presented with a homepage after being authenticated, 
much less appellant's claimed apparatus "used in reverse to prevent unauthorized Internet-ready 
devices from accessing a particular site ," as claimed by appellant (emphasis added). 
Furthermore, merely disclosing that the ISB and ISP perform PAP if no authentication has been 
performed, as in Vaziri, simply fails to even suggest "preventing] unauthorized Internet-ready 
devices from accessing a particular site ," in the manner as claimed by appellant (emphasis 
added). 

It appears that the Examiner has relied on an inherency argument regarding the above 
emphasized claim limitations. In view of the arguments made hereinabove, any such inherency 
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argument has been adequately rebutted, and a notice of allowance or a specific prior art showing 
of such claim features, in combination with the remaining claim elements is respectfully 
requested. (See MPEP 2112) 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, fail to teach or 
suggest all of the claim limitations, as noted above. 

Issue # 5: 

The Examiner has rejected Claims 17 and 43 under 35 U.S.C. 103(a) as being unpatentable over 
Vaziri in view of Himmel in view of Martin et al. ("An Alternative to Government Regulation 
and Censorship: Content Advisory Systems for the Internet"). 

Group #1: Claims 1 7 and 43 

Appellant respectfully asserts that the subject matter of such claims is deemed allowable in view 
of the arguments made hereinabove with respect to Issue #3, Group #1 . 

Issue # 6: 

The Examiner has rejected Claim 58 under 35 U.S.C. 103(a) as being unpatentable over Vaziri in 
view of Sharpe, III et al. (U.S. Patent No. 6,012,961). 

Group #1: Claim 58 

Appellant respectfully asserts that the subject matter of such claims is deemed allowable in view 
of the arguments made hereinabove with respect to the independent Issue #3, Group #1. 

Issue # 7: 
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The Examiner has rejected Claim 59 under 35 U.S.C. 103(a) as being unpatentable over Vaziri in 
view of Reavey et al. (U.S. Patent No. 5,847,698). 

Group #1: Claim 59 

Appellant respectfully asserts that the subject matter of such claims is deemed allowable in view 
of the arguments made hereinabove with respect to Issue #3, Group #1 . 

In view of the remarks set forth hereinabove, all of the independent claims are deemed 
allowable, along with any claims depending therefrom. 
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In the event a telephone conversation would expedite the prosecution of this application, the 
Examiner may reach the undersigned at (408) 971-2573. For payment of any additional fees due in 
connection with the filing of this paper, the Commissioner is authorized to charge such fees to 
Deposit Account No. 50-1351 (Order No. NVIDP322/P001314). 



Respectfully submitted, 



By: /KEVINZILKA/ Date: April 2, 2007 

Kevin J. Zilka 
Reg. No. 41,429 

Zilka-Kotab, P.C. 

P.O.Box 721120 

San Jose, California 95172-1 120 

Telephone: (408) 971-2573 

Facsimile: (408) 971-4660 
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